1. Field of the Invention
This invention relates generally to automated testing of computer software programs and more particularly to automated software quality through automated functional testing using graphical user interfaces.
2. Description of the Related Arts
Software developers commonly spend a great deal of time and money testing the computer programs they develop. This is especially true for development of so-called “mission critical” programs, such as those used in business accounting, payroll and billing systems.
Software testing is viewed as an obstacle to production because it is time consuming and the costs of not testing are theoretical and uncertain. Consequently, software testing is often neglected. One way to balance deployment time with higher software quality resulting from thorough testing is to make testing and development as efficient as possible.
As software becomes increasingly more complex, testing the software also becomes more complex as a large number of unique combinations of paths and modules may be tested for each program. One approach to software testing is to create a test script for testing a software application. These scripts are conventionally written in a general purpose programming language such as Visual Basic, C++ or Java, or in a proprietary language focused on test scripts. The scripts abstractly represent actions that are to be performed by the application under test. The scripts themselves, like computer programs, are compiled and then executed against the application under test.
Conventional approaches that call for creation of test scripts require users to have technical expertise to understand the scripts they are writing, editing and executing. Maintaining test scripts and interpreting test results can be inefficient because of the abstraction inherent in scripting. Users cannot “see” what they are trying to do with the application being tested, and as a result they sometimes spend significant amounts of time identifying required changes and verifying that changes function as expected.
In one previous attempt to address the challenges of scripted testing, a software tool called Mercury QuickTest Pro provides a “screenshot” view that gives users a visual context for creating and maintaining test scripts while seeing the controls they are manipulating. A tree and grid interface textually describes the actions relative to the screenshot view. However, the user is not provided with a visual interface for understanding the relationship of each action and each window to the overall scope of the script. Rather, a hierarchical tree view indicates the relationship of each window to each step in the test script. Thus, the user must still deal with significant abstraction. Further, technical language is still used in much of the text presented to the user, making it difficult for non-technical personnel to make use of such tool. Finally, since such tool is script-based, translation between the visual interface and a script remains a requirement.
Some approaches to “scriptless” automated testing have previously been made. For example, the CERTIFY product produced by Worksoft, Inc. of Dallas, Tex. is marketed as using a “progression testing” approach that requires no scripts or other programming. An expert has to develop a testing execution engine for at least some environments. The engine accepts a limited set of Keywords to be input from tables. The test processes, then, are defined based on the tables. The items in the tables include objects (e.g., “NewBtn PushButton”), actions (e.g., “Press”), descriptions (e.g., “Press NewBtn PushButton”), and what to do on pass or on fail (e.g., “Continue”).
Similarly, published United States Patent Application No. US 2002/0188890, entitled, “System and Method for Testing an Application”, discloses that testing can be performed using “scriptless” transactions. As described in the abstract, “The transaction definition may occur during navigation by a user through a network site while data regarding application is collected. Alternatively, a user may select transactable components or transactions from a list or a group of icons. In still another alternative the transaction definition may be performed automatically using log files or component relationship data.”
Another existing solution, the TestPartner product from assignee Compuware Corporation, includes a tool called the Visual Navigator that simplifies some of the more arcane aspects of creating, executing, and managing scripts.
Notwithstanding existing approaches to making application testing easier for non-technical users, challenges have remained. Usability of testing products for complex applications is still capable of improvement, particularly with regard to providing visual context. The majority of tools are entirely textual in terms of how they present the application under test and the action to be performed against it. An improvement in the visual context is particularly useful for personnel who are non-technical or new to software quality/testing disciplines. This is an important need because it is often Subject Matter Experts (SMEs) for a particular application that could best serve as testers for such application, yet such SMEs are rarely qualified to serve as software quality assurance testers using existing test products.
Therefore, there is a need to have improved systems and processes for scriptless automated software testing.